System and method of looking up and validating a digital certificate in one pass

ABSTRACT

A system and method for a certificate verifier to make a request to a certificate distribution server for a copy of another entity&#39;s digital certificate and to have the certificate distribution center validate it. The certificate distribution center can request the appropriate certificates and validation thereof from a number of certificate authorities or may alternatively obtain copies from a certificate cache and validate the copies against a revocation list server.

PRIORITY CLAIM

[0001] The patent application claims priority from Canadian PatentApplication No. 2,374,195 filed on Mar. 1, 2002 in the Canadian PatentOffice, the contents of which is incorporated herein by reference.

FIELD OF THE INVENTION

[0002] This invention relates to the field of digital certificates. Morespecifically, it is directed to an improved scheme for validatingdigital certificates.

BACKGROUND OF THE INVENTION

[0003] In asymmetric encryption technology, each user generates a pairof keys known as a public key and a private key. The public key iswidely disseminated and used by others to encrypt communicationsintended for the owner of the public key. Once the message has beenencrypted with the public key, it can only be decrypted with thecorresponding private key. This is the basis of public key encryption.

[0004] The problem with this technology is that the sender needs to havea way of guaranteeing that the public key used for encryption doesindeed belong to the recipient. Otherwise, the sender couldunintentionally encrypt a message that could only be decrypted by somemischievous third party. A method was therefore needed for users to beable to have a high degree of assurance that the owner of a public keywas indeed the intended recipient.

[0005] Digital certificates were invented to solve this problem. Arecognized certificate authority issues a certificate binding the publickey of a subscriber to his real world identity. The certificate isdigitally signed by the recognized issuing authority. A message isdigitally signed in effect by encrypting it with a private key. Themessage can then only be decrypted with the corresponding public key,and provided the user has a high degree of trust in the certifyingauthority, he will then have assurance that the public key contained inthe certificate does indeed belong to the user to whom it is bound.

[0006] Digital certificates generally follow the X.509 standard,developed by the International Standards Organization (ISO) and theComité Consultatif Internationale Telegraphique et Telephonique (CCITT).These certificates create a binding between an entity's public key andits identity. Obtaining authentic copies of public key certificates iscritical in deploying secure public key systems. Often a digitalcertificate is stored in a publicly accessible repository such as anLDAP or X.500 directory.

[0007] In practice, implementers of certificate revocation lists havediscovered that they are difficult to manage because they can becomevery large and not usable by some certificate verifiers such assmartcards or mobile phones. Further, since these lists are issued onlyperiodically, there is a time gap between when a certificate is revokedby its issuer and when it appears on a publicly available list ofrevoked certificates. Methods such as the online certificate statusprotocol have been developed as a means to make requests to validationservices to determine whether a particular certificate is currentlyvalid, however, this requires that a certificate verifier make at leasttwo requests, one to obtain a copy of the certificate and another toobtain the current validity status of the certificate. Further requestsmay be required to obtain all certificates needed to construct acertificate chain that can be validated up to a trusted root held by theverifier. In many applications, in particular those where the verifieris a mobile phone, smartcard or other client devices that are relativelyconstrained with respect to storage capacity, processing power andcommunication bandwidth, the current solutions are not practical.

[0008] It will be apparent from the foregoing that prior certificateissuance and validation systems and methods are generally designed toallow a user to obtain a validated digital certificate, but are slow andcumbersome to the user under various circumstances.

SUMMARY OF THE INVENTION

[0009] It is an object of the present invention to provide a system foraccessing and validating a digital certificate, comprising a first setof certificate authorities connected to a communication network and ableto receive and respond to requests for certificates; the first set ofcertificate authorities having a set of hierarchical trust relationshipsamong them, the set of hierarchical trust relationships being verifiedby a set of digital certificates; a certificate holder having a digitalcertificate issued by one of the first set of certificate authorities; acertificate verifier connected to the communication network and having atrust relationship with a second set of certificate authorities; and acertificate distribution center connected to the communication networkand operable to receive a request from the certificate verifier for avalidated copy of the digital certificate, obtain the digitalcertificate from said one of the first set of certificate authorities,obtain a subset of digital certificates of the set of digitalcertificates necessary to validate the digital certificate, and returnto the certificate verifier a validated copy of the digital certificate,wherein the certificate distribution server determines the subset ofdigital certificates of the set of digital certificates based on thesecond set of certificate authorities.

[0010] Preferably, the certificate distribution center is operable toindicate to the certificate verifier that the digital certificate has astatus of invalid, revoked, expired or non-existent.

[0011] Also preferably, there is at least one revocation list serverhaving a list of digital certificates that have been revoked; and acertificate cache, wherein the certificate distribution centeradditionally obtains from the certificate cache a cached copy of one ofthe digital certificate and the set of digital certificates and verifieswith the at least one revocation server the validity thereof prior tocontacting the set of certificate authorities.

[0012] The certificate cache preferably resides at the certificatedistribution center and serves a plurality of certificate verifiers.

[0013] Also preferably, the certificate distribution center deposits asubset of the digital certificate and the subset of digital certificatesobtained from the first set of certificate authorities in thecertificate cache.

[0014] The request from the certificate verifier can indicate a desiredlevel of confidence for the digital certificate's validity or candirects the certificate distribution center to ignore the certificatecache.

[0015] Preferably, the reply to the certificate verifier additionallycomprises a formatted first certificate chain summary.

[0016] Also preferably, the certificate distribution center additionallyconstructs and returns a second certificate chain, based on the secondset of certificate authorities, to the certificate verifier permittingthe certificate verifier to validate the digital certificate of thecertificate distribution center.

[0017] The certificate distribution center preferably has priorknowledge of the second set of certificate authorities trusted by thecertificate verifier.

[0018] In addition, the request from the certificate verifier includes arequested certificate identifier from which each of the first set ofcertificate authorities in parent relationship to the certificate holdercan be identified.

[0019] In another aspect of the invention, there is provided a method ofvalidating and serving a digital certificate, comprising the steps ofreceiving a first request from a certificate verifier for a digitalcertificate; sending a second request to a first certificate authorityhaving issued the digital certificate requested by the certificateverifier; receiving the digital certificate from the first certificateauthority; if the first certificate authority is not trusted by thecertificate verifier, requesting an additional digital certificate froma subsequent parent certificate authority, receiving the additionaldigital certificate from the subsequent parent certificate authority,validating a previous digital certificate with the additional digitalcertificate, and, in the event that said subsequent parent certificateauthority is not trusted by the certificate verifier, repeating thesesteps; and returning the digital certificate to the certificateverifier.

[0020] Preferably, the step of receiving the digital certificate oradditional digital certificate from the certificate authority canalternatively comprise receiving an indication that the digitalcertificate or the additional digital certificate is invalid, the stepsof obtaining additional digital certificates are repeated alsoconditionally on the validity of the previous digital certificate andthe existence of the additional digital certificate and its unrevokedstatus, and the step of returning the digital certificate to thecertificate verifier can alternatively comprise returning a notificationthat the digital certificate is invalid.

[0021] Also preferably, the method additionally comprises the step ofobtaining the digital certificate or the additional digital certificatefrom a certificate cache and validating the digital certificate or theadditional digital certificate using a revocation list in place ofobtaining the digital certificate or the additional digital certificatefrom the first or subsequent parent certificate authorities, in theevent that the digital certificate or the additional digital certificateis available from the certificate cache.

[0022] Further, the method preferably additionally comprises the step ofplacing at least one of the digital certificate and the additionaldigital certificates in the certificate cache once received from thefirst or subsequent parent certificate authority.

[0023] The step of receiving a first request from a certificate verifiercan additionally comprise receiving a desired level of confidence fromthe certificate verifier, and the step of validating the digitalcertificate and the additional digital certificates reflects the desiredlevel of confidence.

[0024] Alternatively, the step of receiving a first request from acertificate verifier comprises receiving from the certificate verifier adirection to ignore the certificate cache.

[0025] Further, the step of returning the digital certificate to thecertificate verifier preferably additionally comprises constructing afirst certificate chain from the digital certificate and the additionaldigital certificates, if any, and returning the first certificate chain,along with the digital certificate, to the certificate verifier.

[0026] Preferably, the step of returning the certificate chain comprisesformatting the first certificate chain and the digital certificate priorto returning the first certificate chain to the certificate verifier.

[0027] The steps of obtaining additional digital certificates arepreferably followed by the step of constructing a second certificatechain, based on the second set of certificate authorities, to thecertificate verifier permitting the certificate verifier to validate thecertificate distribution center, and returning the second certificatechain to the certificate verifier.

[0028] Preferably, the step of constructing a second certificate chainadditionally comprises the step of formatting the second certificatechain prior to returning the second certificate chain to the certificateverifier.

[0029] Also preferably, the step of receiving a first request from acertificate verifier for a digital certificate additionally includes thestep of identifying the first certificate authority and each of thesubsequent parent certificate authorities solely from the informationpresented in the first request, and the steps of obtaining theadditional digital certificates is performed prior to receiving thedigital certificate from the first certificate authority.

BRIEF DESCRIPTION OF THE DRAWINGS

[0030] The present invention will now be described, by way of exampleonly, with reference to certain embodiments shown in the attachedFigures in which:

[0031]FIG. 1 is a block diagram of the prior art method ofauthenticating the public key of an entity;

[0032]FIG. 2 is a block diagram of the method in an embodiment in thepresent invention for authenticating the public key of an entity;

[0033]FIG. 3 is a block diagram of the request data structure sent bythe certificate verifier to a certificate distribution center in apresent embodiment of the invention;

[0034]FIG. 4 is a block diagram of the response data structure sent bythe certificate distribution center to the certificate verifier in apresent embodiment of the invention; and

[0035]FIG. 5 is a flow chart of an embodiment of the method of lookingup and validating a digital signature in one pass.

DETAILED DESCRIPTION OF THE INVENTION

[0036] The general method of certificate authentication as taught underthe aforementioned standards is shown in FIG. 1. In order to obtain avalidated certificate, a verifier may be required to make numerousrequests to various authorities and verify the authenticity of eachcertificate received individually.

[0037] Referring now to FIGS. 2 to 5, the system and method of lookingup and validating a digital certificate in one pass in accordance with afirst embodiment of the present invention is indicated generally at 20.A certificate verifier 24 is provisioned with at least one certificateof a trusted root certificate authority and means to locate and contacta certificate distribution center (CDC) 28. Certificate verifier 24 maybe a desktop or server computer that has a permanent connection orestablishes a temporary connection to a communication network, such asthe Internet. Certificate verifier 24 may know the physical address ofCDC 28 or may know its virtual address that will resolve to CDC 28 bymeans of a resolution system, such as DNS.

[0038] When certificate verifier 24 needs to obtain a copy of a publickey contained in a certificate, and wants assurances that thecertificate is currently valid, in order to verify a digital signatureof or encrypt a message to a certificate holder 32, it transmits acertificate request 36 to CDC 28.

[0039] Certificate request 36 contains a requested certificateidentifier 40 that provides sufficient information for CDC 28 toretrieve the certificate for certificate holder 32 from the appropriateCA. Requested certificate identifier 40 may be information that directlyor indirectly identifies certificate holder 32.

[0040] Certificate request 36 can also contain trusted certificateinformation 44, indicating trust relationships with at least one CA.Trusted certificate information 44 defines the gap in trust that CDC 28must try to bridge with a chain of certificates. Trusted certificateinformation 44 can be a list of the CAs for which trusted certificatesare held, a reference to a list of CAs known or available to CDC 28, orany other information allowing CDC 28 to determine what CAs are trustedby certificate verifier 24.

[0041] Additionally, validated certificate request 36 can optionallycontain a CDC credentials request field 48 that allows certificateverifier 24 to demand a copy of the certificate of CDC 28 and,additionally, any certificates required to construct a chain to a CAtrusted by certificate verifier 24.

[0042] Further, a set of cryptographic security information 52 can beincluded in validated certificate request 36 to prevent a replay attacksuch as a time code or a nonce.

[0043] CDC 28 receives validated certificate request 36 and parses it.The initial task of CDC 28 is to use cryptographic security information52 to verify whether the request was tampered with.

[0044] Once verified, CDC 28 commences acquiring and validating theappropriate certificates. The greatest resources used in constructing aresponse are in looking up the certificate chain of certificate holder32 and validity thereof. CDC 28 may need to lookup these certificates inpublic directories such as LDAP or X.500 directories. CDC 28 looks upthe certificate of certificate holder 32, the certificates of the CAthat issued the certificate of certificate holder 32 and thecertificates of the subsequent parent CAs that demonstrate thehierarchical trust relationships, up to the certificate issued by the CAtrusted by certificate verifier 24. If the CAs trusted by certificateverifier 24 are not a direct or indirect parent of the CA that issuedthe certificate to certificate holder 32, then CDC 28 can continue tolook up certificates until that of the root CA has been obtained.

[0045] CDC 28 can maintain a certificate cache 56 to cache certificatesretrieved in response to certificate requests 36. In this case, CDC 28preferably serves multiple certificate verifiers. Alternatively,certificate cache 56 may be externally located.

[0046] For each certificate required, CDC 28 checks to see if a cachedcopy exists in certificate cache 56. If it does, CA checks with arevocation list server 60 maintaining a list of revoked certificatesthat is updated periodically. Revocation list server 60 can be locatedat CDC 28, such as a process on the same computer making the request oron a separate computer cooperatively comprising CDC 28, or canalternatively be located externally. Alternatively, CDC 28 checks withthe CA that issued the certificate to confirm the validity of thecertificate.

[0047] If CDC 28 does not have access to a cached copy of a requiredcertificate, CDC 28 contacts the CA that issued the certificate for acopy, if available.

[0048] CDC 28 can thus construct a chain of certificates fromcertificate holder 32 to a CA trusted by certificate verifier 24, or toa root CA if no CA in the hierarchy is trusted by certificate verifier24.

[0049] Where CDC credentials request field 48 is employed andcertificate verifier 24 has requested such credentials, CDC 28 canconstruct a chain of certificates from CDC 28 to a CA trusted bycertificate verifier 24, or to a root CA if no CA in the hierarchy istrusted by certificate verifier 24.

[0050] CDC 28 then forms and transmits a certificate response 64 tocertificate verifier 24. Certificate response 64 can include acryptographic hash of the original request for purposes of verifyingsecure receipt of certificate request 36 of certificate verifier 24.

[0051] If CDC 28 was able to find a valid certificate matching therequested parameters, it can include in certificate response 64 thecertificate and certificate chain information up to, but not including,the certificate of a trusted certificate authority specified in therequest 36, or the root CA where no CA trusted by certificate verifier24 was in the chain. Alternatively, CDC 28 can provide a confirmation ofthe credentials of certificate holder 32 in some other format, such as aBoolean response.

[0052] If no certificate matches the requested parameters or if therequested certificate is revoked, has expired or is invalid because ofan incomplete certificate chain to a trusted certificate authority, CDC28 sends a response indicating that no such valid certificate was found.

[0053] Where certificate verifier 24 requests the credentials of CDC 28,CDC 28 can provide its certificate and certificate chain information upto, but not including, the certificate of a trusted root specified inthe request.

[0054] If certificate verifier does not have a trusted root that is in achain containing the requested certificate or a chain containing thecertificate distribution center's certificate, CDC 28 may include thistrusted root but the response may be less meaningful to the certificateverifier.

[0055] The time at which CDC 28 determined the validity of the requestedcertificate can be optionally included in the response.

[0056] Finally, CDC 28 includes its digital signature on the responsecovering the entire contents of the response.

[0057] CDC 28 sends signed certificate response 64 to certificateverifier 24.

[0058] Certificate verifier 24 uses the public key of CDC 28 to verifythe signature on certificate response 64. This key is obtained eitherfrom certificate response 64 itself or by some other method. Certificateverifier 24, if it does not trust this key directly, also verifies thecertificate chain containing this certificate, and resultantly this key,up to a trusted certificate. Certificate verifier 24 also verifies thatthe identity in the certificate returned in certificate response 64containing the public key of CDC 28 matches the identity of CDC 28.

[0059] Certificate verifier 24 also verifies that the cryptographic hash52 of certificate request 64 it sent to CDC 28 matches the cryptographichash 68 in the response. This prevents replay attacks and prevents anadversary from changing the information in the original request.

[0060] Once certificate verifier 24 has determined that certificateresponse 64 is authentic and is a response to the request it made, itcan proceed to extract the requested certificate and certificate chaininformation with the confidence that each certificate in the chain iscurrently valid and not revoked.

[0061] While the foregoing description refers to a system whereby theresponse includes the certificate chain and validation thereof, it iscontemplated that CDC 28 returns a response indicating that thecertificate chain has been validated, but does not include thecertificate chain itself.

[0062] Other variations are within the scope of the invention.

[0063] For example, CDC 28 can have a certificate issued by a CA trusteddirectly or indirectly by certificate verifier 24; for example, the CAwhose root certificate is held by certificate verifier 24. This enablescertificate verifier 24 to trust CDC 28.

[0064] Further, the certificate of CDC 28 can indicate that CDC 28 ispermitted to act in its capacity.

[0065] CDC 28 can maintain state information about which certificateauthorities are trusted by certificate verifier 24.

[0066] Certificate verifier 24 can specify a desired level of confidenceto be satisfied in determining the validity of a requested digitalcertificate. For example, certificate verifier may specify that acertificate obtained from a source other than the issuing certificateauthority only need have been validated within the last month; that is,if the certificate was placed in the cache in the last month or wasdetermined not to have been on a revocation list in the last month, thenthe certificate can be relied on. Further, certificate verifier 24 canspecify for CDC 28 to obtain fresh copies of certificates from theappropriate issuing certificate authorities.

[0067] Requested certificate identifier 40 can disclose not only thename and location of the digital certificate of certificate holder 32,but may also specify those of each subsequent parent certificateauthority including the root certificate authority, such as by using themethod of pseudonyms for identifying certificate chains, as disclosed inco-pending Canadian patent application 2,365,441. If the methoddescribed in co-pending Canadian patent application 2,365,441. is used,then information contained in the response may contain a certificatesequence number.

[0068] Further, where the complete hierarchy can be immediatelyidentified from requested certificate identifier 40 of certificaterequest 36, CDC 28 can perform the necessary procedures to validate eachof the certificate in the certificate chain simultaneously, thusimproving response times.

[0069] The present invention provides a novel system and method forlooking up and validating a digital certificate that is generally lesscumbersome and more rapid for the certificate verifier.

[0070] The invention enables client software to have a smaller sizebecause certificate validation information is gathered and consolidatedby the certificate distribution center. The set up of this software iseasier because it needs to be configured to communicate only with thecertificate distribution center. Network communications are moreefficient because the certificate verifier does not need to establishsessions with different validation authorities or directories.

[0071] The above-described embodiments of the invention are intended tobe examples of the present invention and alterations and modificationsmay be effected thereto, by those of skill in the art.

[0072] This concludes the description of the preferred embodiment of theinvention. The foregoing description has been presented for the purposeof illustration and is not intended to be exhaustive or to limit theinvention to the precise form disclosed. Many modifications andvariations are possible in light of the above teaching and will beapparent to those skilled in the art. It is intended the scope of theinvention be limited not by this description but by the claims thatfollow.

We claim:
 1. A system for accessing and validating a digitalcertificate, comprising: a first set of certificate authoritiesconnected to a communication network and able to receive and respond torequests for certificates; said first set of certificate authoritieshaving a set of hierarchical trust relationships among them, said set ofhierarchical trust relationships being verified by a set of digitalcertificates; a certificate holder having a digital certificate issuedby one of said first set of certificate authorities; a certificateverifier connected to said communication network and having a trustrelationship with a second set of certificate authorities; and acertificate distribution center connected to said communication networkand operable to receive a request from said certificate verifier for avalidated copy of said digital certificate, obtain said digitalcertificate from said one of said first set of certificate authorities,obtain a subset of digital certificates of said set of digitalcertificates necessary to validate said digital certificate, and returnto said certificate verifier a validated copy of said digitalcertificate, wherein said certificate distribution server determinessaid subset of digital certificates of said set of digital certificatesbased on said second set of certificate authorities.
 2. The system foraccessing and validating a digital certificate of claim 1, wherein saidcertificate distribution center is operable to indicate to saidcertificate verifier that said digital certificate has a status chosenfrom the group consisting of invalid, revoked, expired or non-existent.3. The system for accessing and validating a digital certificate ofclaim 1, additionally comprising: at least one revocation list serverhaving a list of digital certificates that have been revoked; and acertificate cache, wherein said certificate distribution centeradditionally obtains from said certificate cache a cached copy of one ofsaid digital certificate and said set of digital certificates andverifies with said at least one revocation server the validity thereofprior to contacting said set of certificate authorities.
 4. The systemfor accessing and validating a digital certificate of claim 3, whereinsaid certificate cache resides at said certificate distribution center.5. The system for accessing and validating a digital certificate ofclaim 3, wherein said certificate cache serves a plurality ofcertificate verifiers.
 6. The system for accessing and validating adigital certificate of claim 3, wherein said certificate distributioncenter deposits a subset of said digital certificate and said subset ofdigital certificates obtained from said first set of certificateauthorities in said certificate cache.
 7. The system for accessing andvalidating a digital certificate of claim 3, wherein said request fromsaid certificate verifier indicates a desired level of confidence forsaid digital certificate's validity.
 8. The system for accessing andvalidating a digital certificate of claim 3, wherein said request fromsaid certificate verifier directs said certificate distribution centerto ignore said certificate cache.
 9. The system for accessing andvalidating a digital certificate of claim 1, wherein said reply to saidcertificate verifier additionally comprises a formatted firstcertificate chain summary.
 10. The system for accessing and validating adigital certificate of claim 1, wherein said reply to said certificateverifier additionally comprises each of said subset of said set ofdigital certificates obtained from said first set of certificateauthorities.
 11. The system for accessing and validating a digitalcertificate of claim 1, wherein said certificate distribution centeradditionally constructs and returns a second certificate chain, based onsaid second set of certificate authorities, to said certificate verifierpermitting said certificate verifier to validate said digitalcertificate of said certificate distribution center.
 12. The system foraccessing and validating a digital certificate of claim 1, wherein saidcertificate distribution center has prior knowledge of said second setof certificate authorities trusted by said certificate verifier.
 13. Thesystem for accessing and validating a digital certificate of claim 1,wherein said request from said certificate verifier includes a requestedcertificate identifier from which each of said first set of certificateauthorities in parent relationship to said certificate holder can beidentified.
 14. A method of validating and serving a digitalcertificate, comprising the steps of: (a) receiving a first request froma certificate verifier for a digital certificate; (b) sending a secondrequest to a first certificate authority having issued said digitalcertificate requested by said certificate verifier; (c) receiving saiddigital certificate from said first certificate authority; (d) if saidfirst certificate authority is not trusted by said certificate verifier:(i) requesting an additional digital certificate from a subsequentparent certificate authority; (ii) receiving said additional digitalcertificate from said subsequent parent certificate authority; (iii)validating a previous digital certificate with said additional digitalcertificate; and (iv) in the event that said subsequent parentcertificate authority is not trusted by said certificate verifier,repeating steps (i) to (iii) as necessary; and (e) returning saiddigital certificate to said certificate verifier.
 15. The method ofvalidating and serving a digital certificate of claim 14, wherein steps(c) and (d) (ii) alternatively comprises receiving an indication thatsaid digital certificate or said additional digital certificate isinvalid, step (d) (iv) additionally comprises a condition that saidprevious digital certificate is validated and said additional digitalcertificate exists and was not revoked, and step (e) alternativelycomprise returning a notification that said digital certificate isinvalid.
 16. The method of validating and serving a digital certificateof claim 14, additionally comprising the step of obtaining said digitalcertificate or said additional digital certificate from a certificatecache and validating said digital certificate or said additional digitalcertificate using a revocation list in place of obtaining said digitalcertificate or said additional digital certificate from said first orsubsequent parent certificate authorities, in the event that saiddigital certificate or said additional digital certificate is availablefrom said certificate cache.
 17. The method of validating and serving adigital certificate of claim 16, additionally comprising the step ofplacing at least one of said digital certificate and said additionaldigital certificates in said certificate cache once received from saidfirst or subsequent parent certificate authority.
 18. The method ofvalidating and serving a digital certificate of claim 16, wherein step(a) additionally comprises receiving a desired level of confidence fromsaid certificate verifier, and the step of validating said digitalcertificate and said additional digital certificates reflects saiddesired level of confidence.
 19. The method of validating and serving adigital certificate of claim 16, wherein step (a) additionally comprisesreceiving from said certificate verifier a direction to ignore saidcertificate cache.
 20. The method of validating and serving a digitalcertificate of claim 14, wherein step (e) additionally comprisesconstructing a first certificate chain from said digital certificate andsaid additional digital certificates, if any, and returning said firstcertificate chain, along with said digital certificate, to saidcertificate verifier.
 21. The method of validating and serving a digitalcertificate of claim 20, wherein step (e) additionally comprisesformatting said first certificate chain and said digital certificateprior to returning said first certificate chain to said certificateverifier.
 22. The method of validating and serving a digital certificateof claim 14, additionally comprising the step of; (f) following step(d), constructing a second certificate chain, based on said second setof certificate authorities, to said certificate verifier permitting saidcertificate verifier to validate said certificate distribution center,and returning said second certificate chain to said certificateverifier.
 23. The method of validating and serving a digital certificateof claim 22, additionally comprising the step of formatting said secondcertificate chain prior to returning said second certificate chain tosaid certificate verifier.
 24. The method of validating and serving adigital certificate of claim 14, wherein said first request in step (a)identifies said first certificate authority and each of said subsequentparent certificate authorities, and step (d) (i) is performed prior toreceiving said digital certificate from said first certificate authorityis step (c).